1. Field of the Invention
The present disclosure relates generally to an improved data processing system and in particular to a method and apparatus for processing data. Still more particularly, the present disclosure relates to a computer implemented method, apparatus, and computer usable program code for examining instructions or code for an application.
2. Description of the Related Art
A debugger is an application that is used to test and debug other applications. An application, in these examples, is program code that may contain one or more programs that form the application. Debugging is a process of finding and reducing the number of errors, flaws, mistakes, failures, faults, and/or defects in program code, such as an application. Debugging is performed to identify changes that may be needed to insure that an application behaves or executes as expected.
When an application crashes, a debugger may show the position in the original code where the crash or error occurred. Debuggers also may offer functions, such as running an application step-by-step. Also, debuggers may allow stopping or pausing the application to examine the current state of the data processing system. This kind of stopping or breaking may occur through a breakpoint. A breakpoint is a location in an application in which program execution is interrupted. A breakpoint provides a mechanism to acquire knowledge and data about a program during execution. A breakpoint may have one or more conditions that determine when an application's execution should interrupt.
During the interruption, a user may inspect various environmental information to determine whether an application is functioning as expected. Some debuggers also have an ability to modify the state of the application during execution, rather than merely observing the execution of the program.
When debugging a threaded application, most debuggers stop all threads when a breakpoint is hit or a step completes. Currently, when a user steps through an application using a debugger, it may appear that the debugger keeps the user in the same thread while stepping occurs. This kind of situation, however, is unlikely. Keeping the user in the same thread and not allowing other threads to run can easily produce a deadlock when the user steps over a semaphore or steps over a routine that contains a mechanism to guard against corrupting a resource.
Currently, this problem is solved in debugger applications by giving the thread that is denoted or identified as the current thread a head start before the debugger starts releasing other threads. This head start may be, for example, a millisecond or a second. This type of process allows the application being debugged to stay in the current thread while stepping through code.
With this type of processing, the first thread that reaches a statement boundary stops at the statement boundary. A statement may require a set of instructions, such as one or more assembly instructions to perform the statement in code. This statement is also referred to as a line. The statement boundary is reached when the first instruction for a statement is about to be executed. The first thread to execute and reach a statement boundary causes the step to complete. The thread reaching a statement boundary becomes the current thread and the source for this thread is displayed and the stop position is indicated.
One problem that may occur is that in many instances multiple threads are running on the same piece of code. When a thread swap occurs during stepping, it often appears to the user that the debugger is malfunctioning or broken because the user believes that the application is in the same thread and the code cannot possibly execute the order indicated on the interface displayed to the user. In other words, with this type of debugging, instructions may not appear to be executing in the order expected by the user. Therefore, it would be advantageous to have an improved method and apparatus for solving the problems described above.